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ABSTRACT  and  Introductory  remarks. 

'■^The  paper  deals  with  procedural  events,  providing  a basis  for  synchronization  and 
scheduling,  particularly  applied  on  real-time  program  systems  of  multiple  parallel  activities 

('multi-task^  nged  f(Jr  convenient  scheduling  mechanisms  for  minicomputer 

5ystems  as  used  in  process  control,  but  so  far  mechanisms  somewhat  similar  to  those 
^ropoTed  here  are  found  only  in  PL/I  among  the  generally  known  high-level  languages 
PL/I  however,  is  not  very  common  on  computers  of  this  size.  Also,  the  mechanisms  in  PL/I 
more  restricted,  as  compared  to  those  proposed  here. 

A new  type  of  boolean  program  variable,  the  EVENTMARK,  is  proposed.  Eventmarks 
represent  events  of  any  kind  that  may  occur  within  a computational  process  and  are 
Mieved  to  give  very  efficient  and  convenient  activation  and  scheduling  of  program 
modules  in  a real-time  system.  An  eventmark  is  declared  similar  to  a procedure,  and  the 
proposed  feature  could  easily  be  amended  as  an  extension  to  existing  languages,  as  well 
as  incorporated  in  future  language  designs.  ^ 
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INTRODUCTION 

Scheduling  and  mutual  synchronization  of  individual  parallel  activities  ("tasks")  in  a real-time 
multiprogramming,  and  possibly  multiprocessing,  system  is  governed  by  conditions  of  various  kinds,  as 
required  by  participating  parallel  activities.  Some  conditions  are  linked  to  time  events,  like 

B *-  (t  > tl ) 0) 

where: 

t is  "wall  clock  time" 

tl  is  some  predetermined  time 

B is  the  condition,  recognized  as  a binary  boolean  quantity. 

Another  typo  of  condition,  not  linked  to  time,  may  be: 

B - (a  = 1)  (2) 

whore  a,  for  example,  can  be  representing  an  external  boolean  signal,  of  some  finite  duration. 

A third  example  represents  a common  case: 

B *-  (x  > y)  (3) 

where  x and  y may  be  computed  quantities. 

Conditions  of  this  kind  are  oithor  generated  in  some  program  modules  or  read  in  througi  the  input 
system  They  are  generally  used  as  activating  conditions  for  program  modules,  different  from  where  they 
arc  generated. 

It  is  well  recognized  that  the  fastest  response  is  obtained  by  use  of  interrupts,  if  the  irigin  of 
events  like  those  mentioned  above  is  some  hardware  source  outside  the  central  processor,  and  if  i*  is  also 
roquired  that  a high  degree  of  central  processor  utilization  oe  maintained. 

none  of  the  languages  in  general  use  are  known  to  have  similar  mechanisms  for  internal)’/  generated 
events,  however,  although  we  can  simulate  interrupts  by  different  means:  We  can  use  trop  instructions, 
special  instructions  activating  the  hardware  interrupt  system,  or  we  can  jump  directly  into  some  special 
place  in  the  interrupt  handling  routine. 

Both  simulated  interrupts  and  active  restarting,  like  Example  1 below,  depend,  however,  on  actions 
in  the  program  module  generating  the  event  (source  module).  We  have  no  means  to  specify,  in  the 
recalling  program  module,  what  arbitrary  conditions  we  want  as  trigger,  if  these  conditions  occur  in  a 
different  module.  The  only  way  a receiving  module  can  discover  if  some  event  has  occurred  in  some  other 
program  module,  is  by  repeated  testing  This  is  very  wasteful  in  respect  of  processor  resource  utilization, 
and  moreover,  this  waste  increases  proportionally  with  required  decreased  response  time.  If  a module  could 
specify  relations  like  eq.  (1)  to  (3)  as  events  which  are  wanted  to  subsequently  trigger  certain  effects,  and 
then  suspend  itself  or  do  something  useful,  we  would  have  a software  feature  resembling  the  hardware 
interrupt  mechanism. 

In  Example  1 , "receiving  module"  suspends  itself  by  an  appropriate  monitor  call.  A subsequent 
monitor  call  WAKE  in  another  program  can  restart  a suspended  program.  In  this  case,  the  call  WAKE(TA) 
will  reactivate  program  TA  to  continue  at  the  point  immediately  following  where  it  was  suspended  (label 
LAI) 

Repeated  testing  is  illustrated  in  Example  2,  where  "receiving  module"  is  Program  TB  in  two 
alternative  versions,  TB1  and  TB2.  A condition  is  changed  in  "source  module"  Program  SB.  Ir  the  case  of 
TB1,  this  program  is  always  active;  repeated  testing  is  the  processortime-westeful  "busy  waiting".  TB2  is 
potentially  less  wasteful,  but  involves  a trade-off  between  response-time  and  processor  time  spendings, 
selectable  by  some  choice  of  value  for  tdelay.  This  seems  to  be  the  method  used  in  [2]  for  recognizing 
change  in  specified  conditions. 

Example  1 : Active  re-starting  from  source  program. 

Program  S/1: 

x:= ; 

WAKE(TA); 
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Program  T 4 

SUSPENO; 

LAI 1 lommcnt  reactivating  ai  LAI , performed  by  call  in  program  SA  Evaluation  o<  soma  function  y:«»(x) ; 


Example  2:  Testing  and  "busy  waiting". 

Program  SB 
x:= ; 

comment  some  function  evaluation  changing  x; 


Program  TBI 

LB  I : if  x < xl  then  go  to  LB  1 ; 

y.. comment  some  function  y*f(x).; 


Program  T B2: 

LB2:  If  x < xl  then  begin 
SUSPEND(tdelay); 

comment  suspend  for  duration  tdelay,  then  test  again.; 
go  to  LB2  end ; 

y.«  .....  comment  some  function  y*f(x).; 


It  is  my  intention,  with  the  present  paper,  to  present  procedural  events  as  a more  efficient  method 
to  perceive  expected  conditions.  I want  to  show  that  such  procedural  events  can  be  implemented  relatively 
easily  and  that  they  can  give  substantial  benefits  in  ease  of  programming  and  scheduling  of  independent 
but  interacting  parallel  activities  in  a multiprogramming/multiprocessor  system,  particularly  real-time  (RT) 
systems  Such  events  constitute  a real  software  counterpart  to  hardware  interrupts,  and  I call  them 
procedural  because  they  resemble  procedures  in  the  way  they  are  declared  and  evaluated. 

Short  reaction  and  processing  time  is  a major  requirement,  if  software  "interrupts  are  to  resemble 
hardware  interrupts;  this  requirement  is  considered  seriously  and  it  makes  internal  testing  and  "busy 

waiting"  quite  superfluous  and  obsolete.  , ......  _.  .. 

To  gam  speed  during  run-time,  some  conditions  are  prepared  during  compilation  time.  Thus,  it 
requires  some  minor  modi.ications  and  additions  to  the  compiler.  If  not  realizable  for  existing  systems,  it 

should  be  very  easy  to  include  in  new  systems,  however.  , , . 

Program  elements  for  synchronization  and  scheduling,  app  ying  procedural  events,  are  covered  only 
summarily  in  a following  section,  since  the  author  has  considered  this  problem  in  a separate  paper  [1], 

DEFINITION  OF  "EVENT” 


I find  the  following  definition  of  the  term  event  applicable: 


An  event  is  a significant  discrete  occurrence  or  incident  which  is  intended  to  affect  some  program 
execution  in  a planned  manner.  The  source  of  an  event  can  belong  logically  to  an  entity  distinctively 
apart  from  the  affected  program  unit  or  units.  An  event  itself  occurs  instantaneously  and  is  of 
infinitesimal  duration.  The  fact  that  an  event  has  occurred  is  indicated  by  an  eventmark  which  is  a 
binary-valued  program  variable  of  type  Boolean, 
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Addit.onaljxplana^^  ^ ^ external  or  'nUrn^Th*  ^ “j.jj,,*"  re^st"  signal  oT  a s^I^cTively 

: sls? j ««-»  b.  - s»™. 

physical  nature.  ractertzed  by  som.  condition  change  within  a program  as  a consequence  ot 

r.lalion  10  0.  .n  .v.nl,  ,1  is  ™,  «!"*»>»“  b.,...n 

E»id.„,,;:irr„;  ?n  irsr  *•  a b*mt  - mMa,k- 

„m.  «. os o1:^ 

Off"  again,  I e made  fatse,  by  K'v.ng  Pd  ^ ^ s|mp)e  examples  o)  defining  equations,  like  (1)  to 

I have,  hitherto,  linked  evenlmarks  J syntactical  correct  boolean  expression  may  be  used, 
(3).  The  beauty  of  the  concept  is,  h°*eve^’  J a /eJing  boo|ean  expression  could  also,  for  example,  be 
defining  a particular  eventmark  Ac  P interrupt.  There  is  virtually  no  limitation,  although 

- ,o  - not 

excessively  more  time. 

declaration  of  eventmarks  and  block  structure  of  the  language 

,«  uaet  two  real-time  programs,  the  one(s)  where  the 

r:=“SSs.'.r--“i — “ “ ‘ 

, (*) 

eventmark  B:=I>«1  i C-.-.vbb.-, 

A bloeK  slrudur.  «hi<h  „ b.  “ M*  » 

advantac.i  also  ,n  combination  wi  pr  c.  wh#ra  „ ,,  daclarnd  It  all  variabl.s  in  th.  d.linmj 

s’-bal,  Mr  SCOP,  will  b.  lb «*-  0,  no 

’-'T^^^lbb^  gallon 

the  free  variables,  or  some  of  them,  be  low  remaining  program  including  the  receiving 

could,  for  example,  be  to  screen  th J^.e  and  receiving  module,  however;  thus  th. 
module(s).  The  eventmark  mui et  be  af  a higher  level  in  the  block  hierarchy. 

evenlmark(s)  would  belon8 fT  fhi  ruUs  of  possible  block  levels  in  usual  procedure  declarations, 
This  consequence  contradicts  the  rules  of  poss.Die  o ^ dependent  va:  .able  name,  i.e. 

where  the  free  variables  may  belong  ° J f the  block’ heading  containing  the  declaration. 

,he  to  be  that  th.  ev®ntmark  declaration  and  th.  procedure 

declaration  are  considered  slightly  ^ nt  ^°d° r^on ^hoJl^b^dec U °^d‘ separately,  as  variables,  either 

All  variables  involved  in  an  eventmar . . . re,a,od  ,0  the  point  where  the  eventmark  declaration 

at  the  same  level  or  at  * declared  elsewhere,  as  a boolean  variable,  either  in  the 
l5  placed  Thus,  the  eventmark  name  blocklevel-structure  of  the  participating  variables  may  be 

same  block-head  or  at  a higher  level,  ^^e^ark  declaration  equation  merely  serves  to  define  the 
chosen  according  to  th.  specific  need ^ an It* bool.in  vanab|.  as  an  eventmark  and 

?.r|rodu‘.«  it’ «w";i|b.Vi4,|r..  V.H.bl.s,  lb  Ih.  compil.r  -Mb.  b.nblint  th.  TEV-tabl.. 


■ MJ  I 1 1 rwifc-  * 
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Th«  typical  block-structure  would,  lor  example,  look  like: 


be  yin  boolean  B,  C,  D;  boolean  array  F[I:10J; 


r(al  begin  PROGRAM  1 real  11,  x,  y;  boolean  a,  b,  a,  q; 
eventmark  B:«»>tl;  D:*qvx>y  end; 


x := 


end ; 

begin  PROGRAM  2 real  p,  s,  — ; 


await  D; 


end-, 


end  main  program; 


Basically  th.  mam  reason  lor  the  n.c.ssity  of  d.viatmg  Irom  identity  with  procedure  declare  on  s 
Serves  a double  function:  The  introduction  and  declaration  of  the  procedure  name  itself,  and 
hat  the  latter  ;#rveS  1 ' d Wlth  ,0rma|  parameters,  body,  and  its  relation  to  the  procedure  name  For 

the  definition io  P , ,h  declaralion  can  conveniently  be  combined,  whereas  they  need  to  be 

»’ £ .. »«» r.*, «*.  .1  <>. 


A NOTE  ABOUT  IMPLEMENTATION  IN  COMPILER 


T.  declaration  like  (4)  will  tell  the  compiler  that  the  ••free"  variables  on  right  hand  side  of  the  defining 
The  declaration  like  > cellared  around  in  the  program,  that  may  cause  an  eventmark  to  become 

*"  ,h0”  ”T',b ;?!•  “ '"Zy  c£,  illacl  an  ...ntbi.rk  directly.  The,  th.  s.mpil.r 

tr„.  and  tha*< '*»'•«•«  ,,h7iv.rta.rk  d.d.r.li.n,  t.oa.r.l.  . I.mpor.ry  t.bl.  (her.  c.ll.d 

LrllV-UbU  wh.r.  th.  Ira.  .ariablas  a.  ."bias,  paw*.,  r.laranc.  Io  Ih.  'Mark  accord! n,  to 
dol.o."  doclarations.  G.n.r.lly,  on.  v.ri.bl.  may  b.  an  .rtom.nt  lor  «.  than  on.  av.nlm.rk,  ,0  that 

ThV,,TC«nS|7»rkldd«l 7ato7^T.mbtoa‘“*bro..dur.  dadaralioo,  aide,  it  d.fin.s  an  .l.abroi. 
. ”,  to  b.  usad  tor  av.lo.I.O"  ol  av.hte.K  valua.  Just  hk.  any  athar  al|.br.iC  axpr.aa.on, 

each  eventmark  will  be  represented  by  a parsed  tree. 


GENERATION  OF  EVENTS 


»v«rv  time  an  assienment  is  encountered,  the  TEV-tablo  is  checked  against 
During  the  compilation,  .very  time  an  assign  en  ^ ^ TEV-Ubl«,  a reference  to  th.  eventmark 

tho  assigned  variab  e * “*  * sys1,m  js  inserted  in  the  generated  code  stream  immediately  following 
evaluation  rou  me  m the  operating  s^tern  is  ^ § ^ ^ compuUd  ,or  a variab|e  that 

Is*  ^free "variable  Tn  7 definition  expression  for  an  eventmark,  this  eventmark  expression  is  also  evaluated, 

and  ^^TnTml'lhro^e^rnr'lystem  (OS)  will  maintain  some  dynamic  scheduling  table,  possibly  tables, 

, . ~ , ' .hat  await  some  event.  Let  us  here  distinguish  between  internal  scheduling 

of  indiv'dual  progra  *RT  programs  are  preempted  due  to  limited  processor  or  memory  resources, 

a e.skw  hadulinr  table(s)  that  the  programmer  is  concerned  with.  The  former  table  should  be  completely 
«“*  bL  ^ wTar.  Orly  Ih.  I.tt.r  lab.,  is  .1  ecash  bar.  and  i,  has.  ..Had  Ih. 

OS'tabja  (Oyhamic  ^ ^ h d Kcordin,ly  Thus,  Ih.  con.arn.d 

program(s)  may  be  activated  very  fast,  shortly  af’er  the  activating  eventmark  became  true. 
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avoidance  of  excessive  slow-down  of  execution 

I,  may  b.  objected,  Ih.t  tw.  . -«2cl 

ir- - ~ : 

13;  — — ^‘=rtpf';^ 

wa^r  at  £^=r^r sr *&£ - - 

nop.„f,bl.  end  «b»  »;'h  t.  p,otP  ”m.r  may  n«'«l '**»  '»»  151  ‘W'*','V 
"bottlenecks"  are  ot  no  concern,  me  pros 


SPECIFICATION  OF  TRIGGERING  EVENTS 

servo  as  typical  cases: 


as  \ypiv<st 

PROG  may  be  started  when  an  ev.ntmark  D becomes  true: 
A designated  program,  PROG,  may  oe  a 

start  (FROG,  D); 

Obviously,  the  program  coni a.- — 


(6) 


,r| v the  program  comamm6  •■■■»  

. A ...cam  may,  a,  any  polo,  In  * 

subsequent  reactivation: 

(7) 

-•£;»«  The  pcottc.m  returnee  ...«*<>"  ■*  v"‘  «h“  C b*t0""‘  ,rU#I 

i A a<larlivi 


....  comment  The  program  

* As  shown  in  [1  ],  synchronization  and  resource-sharing  may  be  controlled  elt.ctiv.ly 
conditional  critical  regions  with  priorities: 

region  v:=p  when  B do  S 
region  v:=p  do  S 
awa i t B 


(8) 

(9) 

(10) 


where: 

v 

P 

B 


designates  Ida  crilioal  aogmn  ,h.  re8ion 

^rv^^.HylneIH.^'»" 

in  (8)1  entrance  into  eonjj»bl«"  * r*g  tu«..dm8  atetement. 


Statement  ,9,  ia  unconditional  and  la  uival.nl  » *>  «>»"  ■*“ 


l 


It'" 


. M0V  caus.  ar.  activation  o<  a monitor  routine  whic.  suspends  th.  calling 

program"  b.  b,  - *•  «”*  " M'i8,i*d! 

* Condition  B it  true  (statement  (8)  and  (10))  eompetins  tor  the  same  region 

: ? “ -«»•« - <8)  *nd  19,1 

" '-rn  *i»Vd“ 

KsL'it  i>  .1=0  vary  conv.ni.nl  lor  Ih.  pro,r.nvn.r. 


COMPARISON  WITH  PL/I  SOFTWARE  INTERRUPTS 


pL„,  on.  can  cp.cily  .n  ..bitr.ry  cond.tion  Ip  C.U..  «.  «'  • P'*C*  " , 

.nd/.r  W.  Ill)  b . oondWon  .nd  ,.n  b.  ..  . r-1  - • 

statement,  tor  example: 


ON  CHECK(namelist) 
BEGIN; 


(12) 


END; 

v.  l.  orriN  - FND-)  will  be  activated  when  any  variable  in  "namelist"  is  changed. 
The  action  block  (enclosed  by  BEGIN  END  ) will ^ mechanism,  with  software  interrupt 

or  any  label  in  "namelist"  is  ^^,or  a certain  statement  is  executed,  as  specif  in  th. 

generated  whenever  a change  ^ execute  a certain  piece  ot  code  whenever  a certain 

namelist  Generally,  ^wever,  wo  do  1 ® ,0  b,  performed  when,  for  example,  the  particular 

variable  is  merely  changed^  R«t*»r,  th  ’ ^ d.p.nds  on  , boolean  function  of  the 

:rr;ss(.).  ss*  * iw — *** * «»  “ 


ON  CHECK(namelist)  IF  boolean  expression  THEN 
BEGIN; 


(13) 


END; 

th.  oh—  h “'i-'-d/^rnZS^^Cb^K»a;r“  ,nd  ,h‘ 

is"* wmewhTsllr  to  th.  proposed  us.  of  declare^. ventmarks.  There  are  some 

differences,  though,  which  at  least  make  that’ it  is  easy  for  th.  compiler  to 

A declared  eventmark  stands  °llTmi  can  b.  .x.cut.d  directly  under  supervision  of  th.  monitor, 
generate  a fast  expression,  which  in  rim  ti  j#  m()r,  int#grat.d  with  the  rest  of  the  application 

with  monitor  priority.  The  construct  1 J)’  , t’h,  .valuation  of  th.  boolean  expression  from  the  rest 

program,  which  makes  it  an  exception,  the  whole  construct  13) 

of  the  code.  Unless  the  compiler  analy  * application  program.  In  relation  to  scheduling, 

will  be  compiled  to  a corresponding^  will  ,Ph.  “cause  th.  whole  IF  - THEN  - 

every  software  interrupt,  caused I by  l |er  ,x#eution,  end  activated  when  priorities  and  other 

BEGIN;  - END;  cod.  piece  Jo  be ' «hed  I d JJ  > of  ,h#  beel.,n  expression  generally  takes  place 

scheduling  conditions  allow.  Since  the  (usually  the  exception),  a considerable 

subst.nli.lly  ™>r.  .«•"  ''"XT.S  ^ TB2 

:,t::PLT”  £*«•»“ 1:1*  W w ***  »• ip  '•“u(ul  ,h" 

ixpr.ssion  is  .vilu.t.d  only  b ch.n,.d. 


L e .yc.Dtion  for  an  expression  like  (13),  the  resulting 

- P'° iou'io" 

" S n °"r;rc"*™y%n°dr  -„mpl.ciW  lor  <h.  pr.sr.nvn.' 

ii)  the  compiler  construction;  e tte  of  i "P1  * n gSrtjjn,  j)  personal  preference  may  be  different, 

»* 

;„ui  » «- — <« 
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